home *** CD-ROM | disk | FTP | other *** search
/ Power Hacker 2003 / Power_Hacker_2003.iso / Exploit and vulnerability / hoobie / secure_shell.txt < prev    next >
Encoding:
Text File  |  2001-11-06  |  6.6 KB  |  136 lines
  1.  
  2. I bumped into a weird 'feature' of ssh 1.2.20. When I run:
  3.  
  4. ssh -L 80:remotehost:80 remotehost
  5.  
  6. as a normal user I get the expected error:
  7.  
  8. Privileged ports can only be forwarded by root.
  9.  
  10. But when I put:
  11.  
  12. LocalForward    80      remotehost:80
  13.  
  14. in my ~/.ssh/config file and connect to the remote host I don't get the
  15. error and port 80 is opened on the localhost (an httpd was not running,
  16. the port must be available). When I connect to it I get a normal
  17. redirection to remotehost:80 over the secure channel. This means however
  18. that a non-root user is able to open privileged ports on the localhost and
  19. redirect them. Is this normal? I checked it on Linux and Solaris.
  20.  
  21.  
  22. =======================================================================
  23.  
  24.  
  25. From a quick glance across the source, ssh rejects attempts to forward privileged
  26. ports for non-root users while parsing the command line arguments - the config file
  27. is read further down in the code, without performing a similar test. The immediate
  28. fix is chmod -s (which will get rid of potential similar holes in ssh as well...) - the
  29. more reasonable method is to move the check into add_local_forward():
  30.  
  31.  
  32. =======================================================================
  33.  
  34.  
  35. You're right.  It it definitely a bug in ssh.  I was just able to
  36. set up port redirection from port 81 on my local machine to port
  37. 80 on a remote machine using the above.
  38.  
  39. The implications are a bit scary -- on a machine where telnet or rlogin
  40. is normally disabled an ordinary user could set up ssh port redirection
  41. of the telnet or rlogin service to a machine under their own control. A
  42. user with ordinary privileges could "run" a Web server on a machine
  43. not currently running a server bound to port 80 by redirecting port 80
  44. to another host, etc.
  45.  
  46. ssh only has this ability because it is normally installed setuid.
  47. Turning off the setuid bit on the ssh client program doesn't appear
  48. to impair the normal operation of ssh and scp, but it definitely
  49. turns off the hole which allows privileged TCP/IP ports to be forwarded.
  50.  
  51. I recommend turning off the setuid bit ('chmod u-s /usr/local/bin/ssh').
  52. until the posted code fix is installed and tested.
  53.  
  54. In fact --unless you are willing to peruse source code for bugs and
  55. will always install patches asap when bug reports come in -- I'd
  56. recommend leaving the setuid bit off the ssh client executable for the
  57. long forseeable future just to be on the safe side.  It means that you
  58. will have to live (on Unix/Linux hosts) without passwordless
  59. connections (both the (1) ordinary 'rhosts' and the (2) 'RSA rhosts'
  60. authentication methods because (1) ssh won't be able to prove that it
  61. is running as a privileged process by opening up a connection from a
  62. port under 1024 on the local host via which to transmit the username of
  63. the current user, nor (2) will it be able to read the local host's
  64. private from the file /etc/ssh_host_key which is normally only readable
  65. by 'root').
  66.  
  67. You can still use the following authentication modes with a non-setuid ssh:
  68. 1.      'user' RSA public key authentication
  69. 2.      Unix password login over the ssh encryption connection.
  70. 3.      S/Key or other non-reusable stronger (than Unix username/
  71.         reusable password) authentication -- if you have installed the
  72.         appropriate modules or modifications into the remote sshd
  73.         (ssh server).
  74.  
  75.  
  76. =======================================================================
  77.  
  78.  
  79. > will have to live (on Unix/Linux hosts) without passwordless
  80. > connections (both the (1) ordinary 'rhosts' and the (2) 'RSA rhosts'
  81. > authentication methods because (1) ssh won't be able to prove that it
  82. > is running as a privileged process by opening up a connection from a
  83. > port under 1024 on the local host via which to transmit the username of
  84. > the current user, nor (2) will it be able to read the local host's
  85. > private from the file /etc/ssh_host_key which is normally only readable
  86. > by 'root').
  87.  
  88. In fact, I also recommed taking this step a little further.  You can help
  89. to ensure that ssh is not used with 'rhosts' or 'RSA rhosts' authentication
  90. even if the setuid bit is set (or later reset), by configuring your router's
  91. ACLs to only accept ssh source ports of 1024 and above.  Of course, this
  92. won't help connections that don't go through the routers, but it adds a
  93. little bit of extra protection and even flexibility.  For example, in an
  94. environment with a medium internal trust level and low external trust level,
  95. it might be desirable to allow 'rhosts' and/or 'RSA rhosts' authentication
  96. internally and yet insure that this relaxed posture is not also a 'feature'
  97. to the outside world.  You could leave the ssh setuid bit on and configure
  98. internal routers to accept ssh source ports of 1022 and above while
  99. configuring border routers to only accept ssh source ports of 1024 and above.
  100. You could then allow the more relaxed posture internally while not also
  101. relaxing your trust of the outside world OR prohibiting more secure 'RSA
  102. only' (augmented with S/Key, etc. if desired) ssh trafic from/to the outside
  103. world.  This could be especially usefull in complex transitive trust
  104. environments.
  105.  
  106. But, as I say, I wouldn't allow these 'features' as a general rule either
  107. and would even help to insure this by blasting their use at the routers as
  108. well.
  109.  
  110.  
  111. =========================================================================
  112.  
  113.  
  114. >In fact, I also recommed taking this step a little further.  You can help
  115. >to ensure that ssh is not used with 'rhosts' or 'RSA rhosts' authentication
  116. >even if the setuid bit is set (or later reset), by configuring your router's
  117. >ACLs to only accept ssh source ports of 1024 and above.  Of course, this
  118. >won't help connections that don't go through the routers, but it adds a
  119. >little bit of extra protection and even flexibility.  For example, in an
  120. >environment with a medium internal trust level and low external trust level,
  121. >it might be desirable to allow 'rhosts' and/or 'RSA rhosts' authentication
  122. >internally and yet insure that this relaxed posture is not also a 'feature'
  123. >to the outside world.  You could leave the ssh setuid bit on and configure
  124. >internal routers to accept ssh source ports of 1022 and above while
  125. >configuring border routers to only accept ssh source ports of 1024 and above.
  126. >You could then allow the more relaxed posture internally while not also
  127. >relaxing your trust of the outside world OR prohibiting more secure 'RSA
  128. >only' (augmented with S/Key, etc. if desired) ssh trafic from/to the outside
  129. >world.  This could be especially usefull in complex transitive trust
  130. >environments.
  131.  
  132. Actually blocking ssh from ports lower than 1024 causes problems who use ssh
  133. as root. When using ssh as root (non-setuid even) ssh uses a reserved port
  134. still.
  135.  
  136.